セキュリティ対策要件
Noセキュリティ対策要件取組
1「安全なウェブサイトの作り方」及び「セキュリティ実装チェックリスト」に準拠して、ECサイトを構築する。
2サーバ及び管理端末等で利用しているソフトウェアをセキュリティパッチ等により最新の状態にする。
3ECサイトの公開前に脆弱性診断を行い、見つかった脆弱性を対策する。
4管理者画面や管理用ソフトウェアへ接続する端末を制限する。
5管理者画面や管理用ソフトウェアへ接続する端末のセキュリティ対策を実施する。
6クレジット取引セキュリティ対策協議会が作成する「クレジットカード・セキュリティガイドラ イン」を遵守する。
7サイト利用者情報の登録時及びパスワード入力時における、不正ログイン対策を実施 する。
8サイト利用者の個人情報に対して安全管理措置を講じる。
9ドメイン名の正当性証明と TLS の利用を行う。
10サイト利用者のログイン時における二要素認証を導入する。
11サイト利用者のパスワードの初期化及び変更といった重要な処理を行う際、 サイト利 用者へ通知する機能を導入する。
12Web サーバや Web アプリケーション等のログや、 取引データ等のバックアップデータを保 管する。
13保管するログやバックアップデータを保護する。
14サーバ及び管理端末において、 セキュリティ対策を実施する。

ウェブアプリケーションのセキュリティ実装 チェックリスト
脆弱性の種類実施項目チェック取組
SQLインジェクション
根本的解決
SQL文の組み立ては全てプレースホルダで実装する。SQLおよびSQLからフォークされた全てのSQLに非依存
SQLインジェクション
根本的解決
SQL文の構成を文字列連結により行う場合は、アプリケーションの変数をSQL文のリテラルとして正しく構成する。SQLおよびSQLからフォークされた全てのSQLに非依存
SQLインジェクション
根本的解決
ウェブアプリケーションに渡されるパラメータにSQL文を直接指定しない。SQLおよびSQLからフォークされた全てのSQLに非依存
SQLインジェクション
保険的対策
エラーメッセージをそのままブラウザに表示しない。SQLおよびSQLからフォークされた全てのSQLに非依存
SQLインジェクション
保険的対策
データベースアカウントに適切な権限を与える。SQLおよびSQLからフォークされた全てのSQLに非依存
OSコマンド・インジェクション
根本的解決
シェルを起動できる言語機能の利用を避ける。主に利用するPerlをにおいてsystem、execなどシェルにアクセスできるコード使用しない構築に努めています。
OSコマンド・インジェクション
保険的対策
シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。渡された許可されない引数などの変数を通さないよう構築に努めています。
パス名パラメータの未チェック/ディレクトリ・トラバーサル
根本的解決
外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。ユーザー入力の検証、ディレクトリトラバーサル攻撃の防止、アクセス制御について留意したシステム構築に努めています。
パス名パラメータの未チェック/ディレクトリ・トラバーサル
根本的解決
ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。留意したシステム構築に努めています。
パス名パラメータの未チェック/ディレクトリ・トラバーサル
保険的対策
ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する。ユーザーからの入力をそのまま利用しない、管理用ファイルについてホワイトリスト方式のアクセス制御を行う、エラーメッセージの適切なシステム構築に努めています。
パス名パラメータの未チェック/ディレクトリ・トラバーサル
保険的対策
ファイル名のチェックを行う。ユーザーからの入力をそのまま利用しない、管理用ファイルについてホワイトリスト方式のアクセス制御を行う、エラーメッセージの適切なシステム構築に努めています。
セッション管理の不備
根本的解決
セッションIDを推測が困難なものにする。ハッシュ化された一時的なセッションIDを用いるシステム構築に努めています。
セッション管理の不備
根本的解決
セッションIDをURLパラメータに格納しない。セッションIDをURLパラメータに用いないシステム構築に努めています。
セッション管理の不備
根本的解決
HTTPS通信で利用するCookieにはsecure属性を加える。Cookieにはsecure属性を設定しています。
セッション管理の不備
根本的解決
ログイン成功後に、新しくセッションを開始する。利用者にログイン機構を提供しないシステム構築を行なっています。
セッション管理の不備
根本的解決
ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する。利用者にログイン機構を提供しないシステム構築を行なっています。
セッション管理の不備
保険的対策
セッションIDを固定値にしない。利用者にログイン機構を提供しないシステム構築を行なっています。
セッション管理の不備
保険的対策
セッションIDをCookieにセットする場合、有効期限の設定に注意する。利用者にログイン機構を提供しないシステム構築を行なっています。
クロスサイト・スクリプティング
HTMLテキストの入力を許可しない場合の対策
根本的解決
ウェブページに出力する全ての要素に対して、エスケープ処理を施す。ユーザーからの入力をそのまま利用せずサニタイズを行うシステム構築に努めています。
クロスサイト・スクリプティング
HTMLテキストの入力を許可しない場合の対策
根本的解決
URLを出力するときは、「http://」や 「https://」で始まるURLのみを許可する。「https://」ではじまるURLのみ許可しています。
クロスサイト・スクリプティング
HTMLテキストの入力を許可しない場合の対策
根本的解決
<script>...</script> 要素の内容を動的に生成しない。ユーザーからの入力をそのまま利用せずタグと判断されるテキストについてはサニタイズを行う構築に努めています。
クロスサイト・スクリプティング
HTMLテキストの入力を許可しない場合の対策
根本的解決
スタイルシートを任意のサイトから取り込めるようにしない。
クロスサイト・スクリプティング
HTMLテキストの入力を許可しない場合の対策
保険的対策
入力値の内容チェックを行う。ユーザーからの入力について監視しcssが読み込まれる可能性があると判断されるテキストについてはサニタイズを行う構築に努めています。
クロスサイト・スクリプティング
HTMLテキストの入力を許可する場合の対策
根本的解決
入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する。ユーザーからのHTML入力は許可しません。
クロスサイト・スクリプティング
HTMLテキストの入力を許可する場合の対策
保険的対策
入力されたHTMLテキストから、スクリプトに該当する文字列を排除する。ユーザーからのHTML入力は許可しません。
クロスサイト・スクリプティング
全てのウェブアプリケーションに共通の対策
根本的解決
HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)の指定を行う。Content-Typeにcharsetを設定しています。
クロスサイト・スクリプティング
全てのウェブアプリケーションに共通の対策
保険的対策
Cookie情報の漏えい対策として、発行するCookieにHttpOnly属性を加え、TRACEメソッドを無効化する。Cookieを発行する場合はHttpOnly属性を加え、TRACEメソッドの無効化をおこなっています。
クロスサイト・スクリプティング
全てのウェブアプリケーションに共通の対策
保険的対策
クロスサイト・スクリプティングの潜在的な脆弱性対策として有効なブラウザの機能を有効にするレスポンスヘッダを返す。CSPを導入し不許可のコンテンツ混入を遮断いたします。
CSRF
根本的解決
処理を実行するページを POST メソッドでアクセスするようにし、その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。前ページで埋め込んだ文字列によるパラメータのチェックを行なっております。
CSRF
根本的解決
処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。根本設計思想としてユーザ情報を保持しないためユーザにパスワード発行しておりません。
CSRF
根本的解決
Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行する。Refererはチェックせず画面の前後関係を確認する仕様を実装しています。
CSRF
保険的対策
重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する。受注が成立した場合に入力されたメールアドレスにメール送信します。サーバにユーザ情報を保持しない設計のため他のトリガーは今のところありません。
HTTPヘッダ・インジェクション
根本的解決
ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用する。HTTP レスポンスヘッダのフィールド値外部から渡されるパラメータの値から動的に生成しません。
HTTPヘッダ・インジェクション
根本的解決
改行コードを適切に処理するヘッダ出力用APIを利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する。基本的にHTTPレスポンスヘッダーを動的に生成しませんが改行コードを適切に扱います。
HTTPヘッダ・インジェクション
保険的対策
外部からの入力の全てについて、改行コードを削除する。外部から入力された改行コードは削除します。
メールヘッダ・インジェクション
根本的解決
メールヘッダを固定値にして、外部からの入力はすべてメール本文に出力する。外部からの入力を未加工でメールヘッダに出力せず必要がある場合は適切なサニタイズを行なっています。
メールヘッダ・インジェクション
根本的解決
ウェブアプリケーションの実行環境や言語に用意されているメール送信用APIを使用する を採用できない場合)。
メールヘッダ・インジェクション
根本的解決
HTMLで宛先を指定しない。
メールヘッダ・インジェクション
保険的対策
外部からの入力の全てについて、改行コードを削除する。
クリックジャッキング
根本的解決
HTTPレスポンスヘッダに、X-Frame-Optionsヘッダフィールドを出力し、他ドメインのサイトからのframe要素やiframe要素による読み込みを制限する。
クリックジャッキング
根本的解決
処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。
クリックジャッキング
保険的対策
重要な処理は、一連の操作をマウスのみで実行できないようにする。
バッファオーバーフロー
根本的解決
直接メモリにアクセスできない言語で記述する。
バッファオーバーフロー
根本的解決
直接メモリにアクセスできる言語で記述する部分を最小限にする。
バッファオーバーフロー
根本的解決
脆弱性が修正されたバージョンのライブラリを使用する。
アクセス制御や認可制御の欠落
根本的解決
アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワード等の秘密情報の入力を必要とする認証機能を設ける。
アクセス制御や認可制御の欠落
根本的解決
認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。

許可されたメールのみ受信トレイに届くホワイトリスト運用です
・契約者様は自社ドメインから送信してください
・契約者以外の方はチャットを開始より送信ください
・関係官庁の方は所管ドメインから送信ください

メール送信しますか?